The present invention relates to methods, systems and computer program products for monitoring computer communication networks and more particularly, for acquiring data related to such networks.
Computer networks have grown increasingly complex with the use of distributed client/server applications, mixed platforms and multiple protocols all on a single physical backbone. The control of traffic on the networks is likewise moving from centralized information technology (IT) departments to distributed workgroups. The growing utilization of computer networks is not only causing a move to new, high-speed technologies, but is at the same time making the operation of computer networks more critical to day-to-day business operations.
The growth in complexity and dependence on computer networks heightens the need for network management tools to design, build and maintain computer networks. The mix of protocols, software applications and vendors of installed hardware on many computer networks generally increases the difficulty of accomplishing network management. This problem may arise in planning or designing changes to a network, monitoring performance of a network, and testing the impact on performance of different hardware and software being installed on a network. The acquisition of data from network components for analysis may also be problematic.
A computer network, for example based on an Internet protocol (IP) architecture, may be described as including a hierarchy of Access, Edge, and Core. Access circuits generally connect to a customer or Customer Provided/Premise Equipment (CPE), which access circuits may be multiplexed, integrated, or aggregated to Edge routers. At the Edge, different protocols (IP, SNA, Appletalk etc) along with different layer 2 transport methods (Fream relay, ATM, Ethernet) may be combined by a network carrier or provider depending on their architecture into Core protocols, such as Internet Protocol (IP). In order to reduce the number and types of different routing and switching systems, a type of edge router device referred to as a Broadband Remote access server (BRAS) or Multi-Service Switching System (MSSS). A Multi-Service Edge (MSE) system may be used, which generally provides protocol conversion from Access protocols (PPP o A or PPP o E etc) to one or more Core protocols (TCP/IP).
As more capable edge routers are utilized, the challenge of making and acting on measurements regarding the traffic on these routers for normal operational support and capacity planning generally increases. These routers can sometimes support approximately 40×1 Gigabit Ethernet interfaces or a combination of Ethernet, 10 Gigabit Ethernet, ATM or Frame Relay interfaces. In comparison, earlier generation networks may support much less traffic and interface diversity. As such, a network management system may now need to consider hundreds if not thousands of devices, each supporting 40×1 Gigabit Ethernet links. Thus the magnitude of the traffic measurement numbers and effort may become staggering.
One difficulty with managing large amounts of traffic to measure and manage is that current data gathering methods may overwhelm the processing power of the edge router. For example, one edge router, the Redback SE 800 router, may provide traffic data responsive to a Simple Network Management Protocol (SNMP) query. This approach generally requires significant involvement of the central processing unit (CPU) of the router, as an external system typically polls the router under management for information relating to many variables per link. If the number of such polls is too great per unit time, the router may cease functioning.
An alternative method for acquiring traffic data from a Redback SE 800 router is to use a BulkStats feature of the router. One problem with the BulkStat approach is that the volume of data to be measured may be massive for high end networks. More particular, a user can generally export Redback Bulkstat data in a series of unique exported files. In this case one Bulkstat “Schema” (example non QoS enabled Ethernet, or QoS enabled ATM or Dot lq VLAN interfaces etc) can be collected and exported. The data fields may be collected every N minutes (e.g., 1 to 5 minute intervals) and the flat file may be exported every M minutes (e.g., every hour). While the exported data may always be uniform with this approach, the router still typically performs these operations for every schema applied to the router. Thus, there may be numerous variations of export schemas even where the gathering of the data and the export of data in one format and file for every interface type is supported, such as with Bulkstats of flat file export from Redback SE 800 and similar routers. However, applying several schemas and collecting unique data per schema and exporting unique files for each schema may still place a significant processing load on the Redback SE 800 or other edge router, which may interfere with the processing of traffic by the router.